Routing of messages from a source node to a destination node in networks, such as for example packet switched networks (PSN's), is performed automatically by the use of routing tables. A routing table is located at each node of the network and contains information as to the link set between nodes that the message is to be transmitted. This information usually includes a preferred or normal route and one or more secondary or failure routes.
Signaling System No. 7 (SS7) interconnects stored program control exchanges, network data bases and intelligent peripherals of telecommunications management networks. SS7 is used to exchange messages and information respectively related to call management and to distributed applications and network management. The protocols of SS7 have been standardized by the "Comite Consultatif International pour le Telephone et le Telegraphe" (CCITT) which is known today as the International Telecommunications Union (ITU)--Telecommunications Standardization Sector (TSS).
To operate properly, the correct routing table information is loaded and stored in each table at system start-up or generation. This information is constant and the routing table is described as "static". The routing tables may also be described as "partial path" because the information stored in each table relates only to the next node on the way to the destination. The integrity of the routing information stored in the tables is fundamental to the normal functioning of the network.
Network communication problems arise when the routing information in tables is incorrect or becomes corrupted. One example of a problem is when the table fails to contain an entry for a destination node causing the message to stop at that node and to fail to make it to its destination. Another problem example occurs when the two node tables contain destination information directed to each other resulting in the message traveling in an endless loop. A third message transmission problem occurs when the message tree between the source node and the destination node results in an excessive length route where the message crosses more STP's than the maximum allowed STP's in the network. Still yet another problem occurs when the signal path through the network is unidirectional. That is to say the message can travel in one direction through the tree from the source node to the destination node but it cannot travel in the reverse direction from the destination node to the source node.
In SS7 networks there are currently two methods used to check the correctness of SS7 routing tables.
The first method involves checking "off-line" the correctness of the routing data before the introduction of this data to the tables. Various simulation methods are used for to check the information. The problem with this method resides in errors introduced during the manual data entry of the information in the table for each node by the operational staff. Further, data corruption can occur after entry. This "off-line" method of testing table data information does not safe-guard against errors occurring during loading of the data in the tables or against errors due to data corruption.
The second method used to check the correctness of SS7 routing tables is a real time check of the table routing data in the network. It consists of auditing "on-line" during network operation the routing data after it has been introduced in the tables. There are two known "on-line" tests in use today to check the correctness of SS7 routing data. These tests are known as the Message Transfer Part (MTP) Routing Verification Test (MRVT) and the Signalling Connection Control Part (SCCP) Routing Verification Test (SRVT). The MRVT and the SRVT check respectively the content of the Message Transfer Part (MTP) routing tables and the content of the SCCP routing tables. These tests are initiated at one or more predetermined source nodes to test the routes messages will follow to respective predetermined destination nodes. Usually each test results in the message following all possible routes to its test destination. This is done by sending multiple test messages and tracking the identities of all nodes crossed by the message. Information on the success of this testing is transmitted back to the destination node. An example of an "on-line" testing procedure is disclosed in U.S. Pat. No. 4,745,593 issued May 17, 1988 to Gilbert M. Stewart.
One problem with this "on-line" testing of routing table information is that such testing requires additional software. In SS7 signalling systems the functioning of the routing verification tests (MRVT and SRVT), besides the need of the MRVT/SRVT software package, require a Transactions Capabilities Application Part (TCAP) software package in each node. TCAP is an SS7 User Part that most SS7 nodes do not have today. From the standpoint of many operators, the benefits of the routing verification tests do not justify the cost of installing a TCAP software package in a node that would have otherwise done without it.
Another problem associated with this routing verification testing is the extra network loading associated with the testing. The networks are already operating under time restraints to deliver messages between source nodes and destination nodes. The introduction of the "on-line" testing to be thorough should be conducted on several nodes over a predetermined time interval. For example, if a network has 20 nodes, there could be hundreds of possible test routes to follow in one test. This one test could significantly load the network. SS7 networks are signalling networks with very stringent delay objectives that the networks can hardly meet when they are overloaded. Consequently, operators are reluctant to perform tests of routing tables in networks.
In view of the foregoing, it can be appreciated that there is a problem with routing table information and the verification of that information particularly after the table information has been loaded into the network. There does not appear to be a solution available to the operator to check actual routing information without unduly overloading the network with test messages thereby placing legitimate messages at risk of being lost.